In a session initiation protocol (SIP) system, a forking call session is a very useful service, by which multiple terminals as a called party can be called simultaneously so as to improve a call completion rate. In an IMS, an SIP is used as a control protocol for various IP multimedia services. In the technical regulation of IMS media security, the forking call session has been ranked as a very important user scenario, and a corresponding security requirement also arises.
FIG. 1a and FIG. 1b show two scenario schematic diagrams of an existing forking call session respectively. FIG. 1a shows a case where the called party refers to a same user who registers multiple terminals, i.e. the multiple terminals have identical public user identification. Herein, the realization of forking call session will be illustrated by a simple example. As shown in FIG. 1a, it is supposed that the called party Bob has a landline phone (UE B3), a mobile phone (UE B2) and a PC (UE B1), and the user Bob registers the three terminals to one common public user identification. When a calling party Alice (UE A) calls the called party Bob, the three terminals are called simultaneously, and the called party Bob can freely select one terminal to respond the call of the calling party Alice and perform a media session with a media key (for example, Ka-b1 or Ka-b2 or Ka-b3) between the selected terminal and the calling party.
FIG. 1b shows a case where the called party refers to multiple users, i.e. each called user has its own unique public user identification. As shown in FIG. 1b, it is supposed that the calling party (UE A) calls any user in a certain area, for example, calling SIP: *@DomainA.com (including UE B, UE C and UE D). Herein, the calling party does not know that the call is forked, and when one terminal has responded the call, other terminals cannot respond the call. This requires that the calling party and any terminal of the called party have unique media key (for example, K1, K2 and K3 for user B, user C and user D respectively), and all terminals except the responding terminal cannot learn the session key already in use so as to guarantee that session contents will not be monitored by or released from other terminals.
In the technical regulation TR33.828 about media security in the IMS, TBS is proposed as an alternative scheme for solving security issues of the IMS media stream. The TBS scheme needs one trusted third party, i.e. a Key Management Server (KMS). FIG. 2 is a schematic diagram illustrating a structure of an existing key management system based on the TBS technology. As shown in FIG. 2, a UE establishes a trusted channel with the KMS by a Bootstrapping Service Function (BSF) through the authentication process of a General Bootstrapping Architecture (GBA), and proxy call session control function (P-CSCF) and service call session control function (S-CSCF) are net elements of the IMS core network. In the structure shown in FIG. 2, in order to realize the forking call session, TBS authentication is required. FIG. 3 is a flowchart illustrating the realization of forking call session by the existing TBS. As shown in FIG. 3, it is supposed that user A and user B have respectively established a secure connection with the KMS by means of the GBA, herein, if the GBA is unavailable, other existing authentication methods can be used for establishing the secure connection with the KMS. In order to establish a secure media channel between the user A and the user B, the following steps are included.
Step 301: a user A sends a ticket request for applying a ticket of a media key to a KMS.
Step 302: the KMS generates the media key and ticket of the user A, and feeds the media key (KT_A) and the ticket of the user A back to the user A.
Step 303-step 304: the user A generates one random number Mod_A, makes an INVITE message include the random number Mod_A and the ticket, and sends the message to the user B through the IMS network.
Step 305-step 306: a terminal of the user B receives the INVITE message, stores the random number Mod_A, makes a forking media key (KF_AB) request include the ticket, and sends the request to the KMS.
Step 307: the KMS receives the ticket, and generates one random number Mod_B after checking that the received ticket is consistent with the ticket fed back to the user A, and generates one forking media key (KF_AB) based on the KT_A of the user A and the random number Mod_B.
Step 308: the KMS sends the KF_AB and random number Mod_B to the terminal of the user B.
Step 309: the terminal of the user B sends the random number Mod_B to the user A.
Step 310: the user A generates the forking media key (KF_AB) based on the random number Mod_B and KT_A. Then, the user A and the user B carry out secure media session by using the identical KA_AB.
It is easy to see from the flowchart in FIG. 3 that media security of forking call session can be realized based on the TBS technology. However, on the one hand, the user needs to request the KMS for the ticket in the TBS solution, thus additional signaling interaction process is added. On the other hand, the KMS needs to generate corresponding random number and forking media key for each called terminal, thus the storage load and calculation load of the KMS are greatly increased.
In the technical regulation of media security of the IMS, except the TBS technology, an Otway-Rees key agreement protocol is another alternative scheme proposed together with the TBS scheme for solving the security issues of the IMS media stream. The Otway-Rees key agreement protocol is an authentication and password exchange protocol. Key agreement can be carried out based on the Otway-Rees key agreement protocol. However, for the forking call session, no practicable solution has been given based on the Otway-Rees key agreement protocol as yet. In combination with FIG. 1a, it is supposed that a calling party Alice calls a called party Bob, and the Otway-Rees key agreement protocol is described briefly.
First, the calling party Alice generates a message EKAT (I, A, B, RA) comprising an index number I, name A of the calling party Alice, name B of the called party Bob and a random number RA, and the message is encrypted by using a shared key between the calling party Alice and Trent; the calling party Alice sends the index number, the name A of the calling party Alice, the name B of the called party Bob and the message encrypted by the calling party Alice to the called party Bob. This is simply expressed as follows: A→B: I, A, B, EKAT (I, A, B, RA).
Then, the called party Bob generates a message EKBT (I, A, B, RB) comprising a new random number RB, the index number I, the name A of the calling party Alice and the name B of the called party Bob, and the message is encrypted by using a shared key between the called party Bob and the Trent; the called party Bob sends the message encrypted by the calling party Alice, the index number I, the name A of the calling party Alice, the name B of the called party Bob and the message encrypted by the called party Bob to the Trent. This is simply expressed as follows: B→T: I, A, B, EKAT (I, A, B, RA), EKBT (I, A, B, RB).
Next, the Trent generates a random session key K and then generates two messages. One message is generated by encrypting the random number generated by the calling party Alice and the random session key K by using the shared key between the Trent and the calling party Alice, the other message is generated by encrypting the random number generated by the called party Bob and the random session key K by using the shared key between the Trent and the called party Bob. The Trent sends the two encrypted messages and the index number I to the called party Bob. This is simply expressed as follows: T→B: I, EKAT (K, RA), EKBT (K, RB).
Finally, the called party Bob forwards the received message that is encrypted by using the shared key between the Trent and the calling party Alice to the calling party Alice. This is simply expressed as follows: B→A: EKAT (K, RA).
In the existing non-IMS system, a traditional technology for solving media security of SIP forking call session scenario is approximately as follows: a calling terminal and a called terminal respectively provide a key parameter for generating a media key and then finally come to an agreement on a media key by exchange of key parameters. For example, for an MIKEY-DH protocol, the calling terminal and the called terminal respectively provide half key parameter, exchange key parameters and come to an agreement on the key by Session Description Protocol (SDP) offer/answer mode and Diffie-Hellman key exchange (DH) algorithm. SDES (SDP Description) is similar to the MIKEY-DH protocol. The drawback of the SIP forking call session technology in the traditional non-IMS system is that, in the forking call session scenario, the calling terminal has to independently come to an agreement on the key with all forked called terminals, this dynamic key agreement has quite high requirement on processing capacity and calculation capacity of the calling terminal; and the MIKEY-DH protocol itself also may be threatened by DOS due to relatively large calculation load and may need the support of Public Key Infrastructure (PKI). In order to reduce the processing load as much as possible, generally a delay mechanism is added, i.e. none of called terminals sends a reply including a key parameter to the calling terminal until a certain terminal responds, then the responding terminal sends a key parameter so as to come to an agreement on the media key with the calling terminal. However, this method does not provide a new key agreement mechanism, just reduces the processing load of the calling terminal, besides, as the key agreement is not yet ended when response, the media stream at this time is not protected by encryption, thus resulting in a new delay problem that the calling terminal and the responding terminal have to come to an agreement on the media key after response. Therefore, on the one hand, the mode of adding delay mechanism is neither able to realize agreement on key, on the other hand, nor really solves the problems such as large processing load and high requirement on the calculation capacity.